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DETAILED ACTION 

Claim Rejections - 35 USC §103 

The following is a quotation of 35 U.S. C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

Claims 1, 2, and 4-65 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Spencer (U.S. 6,633,907) in view of Fascenda (U.S. 6,560,604), in further view of Official 
Notice. 

As per claim 1 , Spencer teaches a method for automated provisioning of networks, 
comprising the steps of: receiving at least one unsolicited command to be executed on a network 
device (column 1, lines 56-67; column 2, lines 60-63; column 4, lines 3-31); reading parameters 
from a network data store related to said network device (column 6, lines 6-65; column 7, lines 
33-65); determining which commands should be executed on said network device based on the 
parameters read (column 7, line 66 - column 8, line 37); and executing the at least one command 
on said network device only if it is determined that the at least one command should be executed 
(column 7, line 66 - column 8, line 37). Though Spencer teaches the reading of network 
parameters from a data store, it is not specifically taught that the network parameters are read 
from a network database, and though suggested by the fact that only those commands that were 
desired by the user will be executed on the network device, Spencer does not specifically teach 
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the predetermination of whether a command can properly be executed on a device, and executing 
it, only if it can be. Fascenda teaches an automated provisioning system, including receiving at 
least one unsolicited update to be executed on a network device (column 19, lines 29-67; column 
20, lines 16-28); reading parameters from a network database related to a network device 
(Abstract; column 3, lines 4-56; column 16, line 64 — column 17, line 38); determining whether 
the at least one command can properly be executed on said network device based upon the 
parameters read (column 19, lines 29-67); and executing the at least one command on said 
network device only if it is determined that the at least one command can be properly executed 
(column 19, lines 29-67; column 20, lines 16-28). It would have been obvious to one of ordinary 
skill to include the use of a database to discern whether a command can be executed on a device, 
as taught by Fascenda in the system of Spencer. The motivation for doing so lies in the fact that 
validity checks can be performed before the changes are made, conserving system resources, for 
example. Both inventions are from the same field of endeavor, namely the automated 
provisioning of networks. Spencer-Fascenda teaches the provisioning of many types of 
networks, but does not per se limit the provisioning to a computer network. Official Notice is 
taken that it would have been obvious to specifically limit the provisioning process to a computer 
network only, as claimed, as this constitutes a design choice known by one of ordinary skill. 

As per claim 2, Spencer-Fascenda teaches the method of claim 1, wherein the at least one 
command is executed by an agent on said network device (Spencer: column 9, lines 16-62). 

As per claim 4, Spencer-Fascenda teaches the method of claim 1, further comprising the 
steps of: receiving a message that at least one command is to be executed from a secure 
provisioning network (Spencer: column 9, lines 16-62). Spencer-Fascenda does not specifically 
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teach the requesting of verification of the validity of the message. Official Notice is taken that it 
would have been obvious to one of ordinary skill in the art at the time of the invention to include 
a method to request the validity of a command message. When commands are given, it must be 
certain that these commands are coming from the correct place, so as to prevent fraudulent 
rollbacks or configurations. Including a specific verification scheme would prevent against 
undue rollbacks and faulty configurations. Including a security measure constitutes a design 
choice and therefore does not constitute a patentable distinction. 

As per claim 5, Spencer-Fascenda teaches the method of claim 4, wherein the step of 
verifying is accomplished by way of communicating with a communication gateway of the 
secure provisioning network (Spencer: Figure 2; column 3, lines 52-54). 

As per claim 6, Spencer-Fascenda teaches the method of claim 1, wherein the step of 
determining is based on reading software packaging parameters (Spencer: Figures 2, 3; column 
2, lines 7-12; where the figures show different types of services, or packages, being provisioned, 
and the SCOs provisioning their own online service implies a determining process by package, 
where certain parameters would lead to certain services being provisioned). 

As per claim 7, Spencer-Fascenda teaches the method of claim 6, wherein the software 
packaging parameters comprise compatibility requirements (Spencer: column 4, lines 10-21; 
where the existence of distinct software packages to be provisioned implies the existence of 
compatibility requirements. Compatible SCOs must be used to provision the appropriate 
service). 
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As per claim 8, Spencer-Fascenda teaches the method of claim 6, wherein the software 
packaging parameters comprise software roles (Spencer: column 4, lines 10-21; where the 
different services constitute different software roles.). 

As per claim 9, Spencer-Fascenda teaches the method of claim 7, wherein the 
compatibility requirements comprise software roles' compatibility requirements (Spencer: 
column 4, lines 10-21; where the different services, or software roles, inherently possess 
compatibility requirements, as evidenced by the use of different SCOs for different services.). 

As per claim 10, Spencer-Fascenda teaches the method of claim 6, but does not 
specifically teach the use of operating system parameters as software packaging parameters. 
Official Notice is taken that it would have been obvious to one of ordinary skill in the art to 
include operating system parameters as packaging parameters at the time of the invention, as it is 
well known in the art. The motivation for doing so is to allow for another type of parameter to 
be used to further classify the provisioning process. 

As per claim 11, Spencer-Fascenda teaches the method of claim 7, but does not 
specifically teach the use of operating system compatibility requirements as compatibility 
requirements. Official Notice is taken that it would have been obvious to one of ordinary skill in 
the art to include OS compatibility requirements as compatibility requirements, as it is well 
known in the art. The motivation for doing so is to prevent the loading of incompatible operating 
systems, which would lead to inefficiency in the provisioning process. 

As per claim 12, Spencer-Fascenda teaches the method of claim 6, wherein the software 
packaging parameters comprise parameters regarding specific customer account requirements 
(Spencer: column 4, lines 10-11). 
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As per claim 13, Spencer-Fascenda teaches the method of claim 7, wherein the 
compatibility requirements comprise requirements regarding specific customer account 
compatibility (Spencer: column 4, lines 12-16; column 3, lines 48-50; where the user chooses 
which services are needed, and the master object determines whether the user is allowed access, 
thus constituting compatibility.). 

As per claim 14, Spencer-Fascenda teaches the method of claim 8, wherein the software 
roles comprise customer account software roles (Spencer: column 4, lines 10-21; where the 
customer account governs which roles are provisioned). 

As per claim 15, Spencer-Fascenda teaches the method of claim 9, wherein the software 
roles compatibility requirements comprise account software roles compatibility requirements 
(Spencer: column 4, lines 10-21; where the customer chooses which software roles are required 
to be provisioned). 

As per claim 16, Spencer-Fascenda teaches the method of claim 6, but does not 
specifically teach the use of device parameters as software packaging parameters. Official 
Notice is taken that it would have been obvious to one of ordinary skill in the art at the time of 
the invention to include this limitation, as it is well known in the art. The motivation for doing 
so is to prevent incompatible devices from being loaded, which would lead to inefficiencies in 
the provisioning process. 

As per claim 17, Spencer-Fascenda teaches the method of claim 16 on the basis of 
obviousness, but does not specifically teach the use of device interface parameters as device 
parameters. Official Notice is taken that it would have been obvious to one of ordinary skill in 
the art at the time of the invention to include this limitation, as it is well known in the art. The 
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motivation for doing so is to allow for the compatibility of device interfaces to be a determining 
factor in the provisioning process, allowing for further efficiency. 

As per claim 18, Spencer-Fascenda teaches the method of claim 17 on the basis of 
obviousness, but does not specifically teach the use of internet protocol address parameters as 
device interface parameters. Official Notice is taken that it would have been obvious to one of 
ordinary skill in the art at the time of the invention to include this limitation, as it is well known 
in the art. The motivation for doing so is to allow certain IP addresses to access specific 
provisioning services which are better suited to provision a certain IP address requesting a 
specific type of service. This allows for further efficiency in the provisioning process. 

As per claim 19, Spencer-Fascenda teaches the method of claim 17 on the basis of 
obviousness but does not specifically teach the use of interface type parameters as interface 
parameters. Official Notice is taken that it would have been obvious to one of ordinary skill in 
the art to include this limitation, as it is well known in the art. The motivation for doing so is to 
prevent incompatible interface types from being used in the provisioning process. Interface 
types should be as efficient as possible, allowing for specific interfaces to correspond to specific 
services being provided. This allows for further efficiency in the provisioning process. 

As per claim 20, Spencer-Fascenda teaches the method of claim 16 on the basis of 
obviousness but does not specifically teach the use of interface components parameters as device 
parameters. Official Notice is taken that it would have been obvious to one of ordinary skill in 
the art to include this limitation, as it is well known in the art. The motivation for doing so is to 
prevent the use of incompatible or disallowed interface components in the provisioning process. 
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For the invention to function, compatible interface components must be used, or it will fail, so 
there must be a parameter in which only compatible interface components can be used. 

As per claim 21, Spencer-Fascenda teaches the method of claim 16 on the basis of 
obviousness but does not specifically teach the use of memory components parameters as device 
parameters. Official Notice is taken that it would have been obvious to one of ordinary skill in 
the art to include this limitation, as it is well known. The motivation for doing so is to allow only 
those devices that meet certain memory requirements to be used in the provisioning process, 
adding to the invention's efficiency. 

As per claim 22, Spencer-Fascenda teaches the method of claim 16 on the basis of 
obviousness but does not specifically teach the use of storage components parameters as device 
parameters. Official Notice is taken that it would have been obvious to one of ordinary skill in 
the art to include this limitation, as it is well known. The motivation for doing so is to allow only 
those devices that meet certain storage type requirements to be used in the provisioning process, 
adding to the invention's efficiency. 

As per claim 23, Spencer-Fascenda teaches the method of claim 16 on the basis of 
obviousness, but does not specifically teach the use of central processing unit parameters as 
device parameters. Official Notice is taken that it would have been obvious to one of ordinary 
skill in the art to include this limitation, as it is well known. The motivation for doing so is to 
allow only CPUs that meet certain requirements to be used in the provisioning process, adding to 
the invention's efficiency. 

As per claim 24, Spencer-Fascenda teaches the method of claim 7, but does not 
specifically teach the use of device compatibility requirements as compatibility requirements. 
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Official Notice is taken that it would have been obvious to one of ordinary skill in the art to 
include this limitation, as it is well known. The motivation for doing so is to allow only devices 
that are compatible with the system to be used, since the invention will fail if incompatible 
devices are used. 

As per claims 25-31, Spencer-Fascenda teaches the method of claim 24 on the basis of 
obviousness. These claims are rejected on the same bases as claims 17-23 respectively, as 
compatibility requirements are specificities of parameters used in the invention and obvious in 
the same manner. 

As per claim 32, Spencer-Fascenda teaches the method of claim 8, but does not 
specifically teach the use of device roles compatibility requirements as software roles 
compatibility requirements. Official Notice is taken that it would have been obvious to one of 
ordinary skill in the art to include this limitation. The motivation for doing so is the necessity of 
using devices compatible with software roles, which, in turn, must also be compatible with the 
system to be able to provide provisioning services. The invention would fail if these 
requirements were not met. 

As per claim 33, Spencer-Fascenda teaches the method of claim 9, but does not 
specifically teach the use of device roles as software roles. Official Notice is taken that it would 
have been obvious to one of ordinary skill in the art to include this limitation, since software 
roles necessitate the use of devices. The inclusion of device roles as software roles allows for a 
better system of grouping by certain characteristics, than if device roles were not included as a 
classification of software roles. The inclusion of this limitation makes for easier grouping of 
software roles, which can then be used as parameters. 
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As per claim 34, Spencer-Fascenda teaches the method of claim 6, but does not 
specifically teach the use of application packaging parameters as software packaging parameters. 
Official Notice is taken that it would have been obvious to one of ordinary skill in the art to 
include this limitation, as it is well known in the art. Application packaging parameters are 
merely specificities of software packaging parameters. Forjudging whether a command can be 
executed by software packaging parameters, application packaging parameters must be known, 
since they are a key part of software parameters. 

As per claim 35, Spencer-Fascenda teaches the method of claim 7, but does not 
specifically teach the use of application compatibility requirements as compatibility 
requirements. Official Notice is taken that it would have been obvious to one of ordinary skill in 
the art to include this limitation, as it is well known. It is a necessity to have applications 
compatible with the system for the invention to have any type of utility, and thus the requirement 
of compatible applications is integral. 

As per claim 36, Spencer-Fascenda teaches the method of claim 8, but does not 
specifically teach the use of application software roles as software roles. Official Notice is taken 
that it would have been obvious to one of ordinary skill in the art to include this limitation, since 
application software roles are an important part of software roles. The individual applications 
govern the characteristics of the software roles, so their inclusion as software roles is obvious. 

As per claim 37, Spencer-Fascenda teaches the method of claim 36 on the basis of 
obviousness, wherein the application software roles define a group of services (column 3, lines 
57-61; where the SCOs administer the application software which have varying roles. These 
varying roles correspond to a variety or services.). 
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As per claim 38, Spencer-Fascenda teaches the method of claim 9, but does not 
specifically teach the use of application roles compatibility requirements as software roles 
compatibility requirements. Official Notice is taken that it would have been obvious to one of 
ordinary skill in the art to include this limitation. The relationship between application roles and 
software roles is discussed in the discussion of claim 36. For the invention to have any utility, 
compatibility requirements of software roles and application roles must match, since applications 
are part of the overall software. It is thus obvious and necessary to include application roles 
compatibility requirements in software roles compatibility requirements. 

As per claim 39, Spencer-Fascenda teaches the method of claim 38 on the basis of 
obviousness, wherein the application roles compatibility requirements define a group of services 
(column 3, lines 57-61; where the SCOs administer the application software, each with certain 
compatibility requirements. These applications correspond to various services. For the 
invention to function, the compatibility requirements must be met, since the applications will 
govern the use of the group of services, which thus defines the group.). 

As per claim 40, Spencer-Fascenda teaches the method of claim 6, but does not 
specifically teach the characteristic of software packaging parameters relating to a variety of 
network service tiers. Official Notice is taken that it would have been obvious to one of ordinary 
skill in the art at the time of the invention to include this limitation, as the various ISPs (or 
network service tiers) would ultimately be the entities providing the provisioning services 
(column 2, lines 60-64). These services would come in the form of software packages. Thus the 
software parameters must be governed by the specific varieties of network service tiers. 



Application/Control Number: 09/838,135 Page 12 

Art Unit: 2445 

As per claim 41, Spencer-Fascenda teaches the method of claim 7, but does not 
specifically teach the compatibility requirements being governed by network service tiers. 
Official Notice is taken that it would have been obvious to one of ordinary skill in the art at the 
time of the invention to include this limitation, as the various ISPs (or network service tiers) 
would ultimately be the entities providing the provisioning services (column 2, lines 60-64). 
Thus, for the invention to function, the network service tiers must be compatible with the rest of 
the system. Internet services must have compatibility requirements since they ultimately govern 
the provisioning process. 

As per claim 42, Spencer-Fascenda teaches the method of claim 6, but does not 
specifically teach the use of configuration parameters to define software packaging parameters. 
Official Notice is taken that it would have been obvious to one of ordinary skill in the art at the 
time of the invention to include this limitation, as it is well known in the art. Software packaging 
parameters are specificities of configuration parameters and generally represent a subset of 
configuration parameters. It would thus be obvious to group them under the category of 
configuration parameters. 

As per claims 43-47, Spencer-Fascenda teaches the method of claim 42 on the basis of 
obviousness. Claims 43-47 are rejected on the same basis of obviousness of claim 42, as Official 
Notice is taken that all of the components are well known and obvious subsets of configuration 
parameters, and it would have been obvious to one of ordinary skill in the art to include these 
limitations. The motivation for doing so is because the addition of these components allows for 
the use of various parameters, thus allowing for system compatibility, efficiency, and utility. 
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As per claim 48, Spencer-Fascenda teaches the method of claim 47 on the basis of 
obviousness, but does not specifically teach the use of device role configuration parameters as 
role configuration parameters. Official Notice is taken that it would have been obvious to one of 
ordinary skill in the art to include this limitation, as it is well known. The motivation for doing 
so lies in the fact that the device characteristics are an integral part of the invention, and it is thus 
necessary for device role parameters to exist as role configuration parameters, as in the example 
of compatibility, the invention would not function if the device configuration is incompatible. 
As a result, there must be parameters for the device configuration in place to account for this. 

As per claim 49, Spencer-Fascenda teaches the method of claim 48 on the basis of 
obviousness, wherein the device role configuration parameters comprise device role history 
configuration parameters (Spencer: column 9, lines 9-11, 56-61; where the rollback process 
depends on a configuration history. This history is part of the device role configuration 
parameters, since it is possible in certain situations that this configuration will be used.). 

As per claim 50, Spencer-Fascenda teaches the method of claim 7, but does not 
specifically teach the use of configuration compatibility requirements as compatibility 
requirements. Official Notice is taken that it would have been obvious to one of ordinary skill in 
the art to include this limitation, as it is well known in the art. The motivation for doing so lies 
in the fact that configuration compatibility requirements must match other compatibility 
requirements for the invention to function properly. Without criteria for proper configuration, 
there would be no consistency in configuration compatibility, giving rise to incompatible 
configurations being loaded. This would lead to the invention's dysfunction and would thus 
defeat its purpose. 
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As per claims 51-55, Spencer-Fascenda teaches the method of claim 50 on the basis of 
obviousness. Claims 51-55 are rejected on the same basis of obviousness of claim 50, as Official 
Notice is taken that all of the components are well known and obvious subsets of configuration 
compatibility parameters, and it would have been obvious to one of ordinary skill in the art to 
include these limitations. The motivation for doing so is because the addition of these 
components allows for the use of various compatibility parameters, thus allowing for system 
compatibility, efficiency, and utility, by allowing only those configurations that will function 
with the system. 

As per claim 56, Spencer-Fascenda teaches the method of claim 55 on the basis of 
obviousness, but does not specifically teach the use of device role configuration compatibility 
requirements as role configuration compatibility requirements. Official Notice is taken that it 
would have been obvious to one of ordinary skill in the art to include the device role 
configuration as a configuration compatibility requirement. The motivation for doing so lies in 
the fact that the device role is an integral part in the system as a whole, and thus must be 
consistent with the other compatibility requirements for the invention to function. Criteria of the 
device's function must be met for the invention to function, and thus a device role configuration 
compatibility requirement is necessary. 

As per claim 57, Spencer-Fascenda teaches the method of claim 56 on the basis of 
obviousness, wherein the device role configuration compatibility requirements comprise device 
role history configuration compatibility requirements (Spencer: column 9, lines 9-11, 56-61; 
where the rollback process depends on a configuration history. This history is part of the device 
role configuration parameters, since it is possible in certain situations that this configuration will 
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be used. It is therefore implied that old device role configuration compatibility requirements are 
depended upon for any rollback process to be possible). 

As per claim 58, Spencer-Fascenda teaches the method of claim 1, wherein the step of 
executing the at least one command is limited to entities having an approved access level to 
execute the at least one command (Spencer: column 2, lines 4-6). 

As per claim 59, Spencer-Fascenda teaches the method of claim 58, wherein the access to 
execute the at least one command is defined in an access control list (Spencer: column 3, lines 
43-50; where the denial of certain users to access back-end servers implies the use of an access 
control list). 

As per claim 60, Spencer-Fascenda teaches the method of claim 58 on the basis of 
obviousness, but does not specifically teach the definition of the access control list by domain 
name server. Official Notice is taken that it would have been obvious to one of ordinary skill in 
the art to include this limitation, as it is well known in the art. The motivation for doing so lies 
in the fact that access to a server is initialized by the domain name server address. If an 
unauthorized DNS is attempting to access the provisioning system, the existence of safeguard, in 
the form of an authorization list to prevent this, is well known in the art. 

As per claim 61, Spencer-Fascenda teaches the method of claim 58, wherein the entity 
executing the at least one command comprises an agent (Spencer: column 3, lines 43-54; where 
the SCO is the agent, and its access level is approved by the master object). 

As per claim 62, Spencer-Fascenda teaches the method of claim 61, but does not 
specifically teach the limiting of access to the agent by the domain name server address of the 
network device. Official Notice is taken that it would have been obvious to one of ordinary skill 
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in the art to include this limitation, as it is well known in the art. The motivation for doing so 
lies in the fact that access to a server is initialized by the domain name server address. If an 
unauthorized DNS is attempting to access the provisioning system, the disallowance of this act, 
based on the DNS address, is well known in the art. 

As per claim 63, Spencer-Fascenda teaches the method of claim 9, but does not 
specifically teach the relation of a network device's IP address to the software roles compatibility 
requirements. Official Notice is taken that it would have been obvious to one of ordinary skill in 
the art to include this limitation, as it is well known in the art. The motivation for doing so lies 
in the fact that an IP address of a network must be compatible for proper provisioning to take 
place. Therefore, there must exist criteria to govern whether an IP address is compatible. 

As per claim 64, Spencer-Fascenda teaches the method of claim 9, but does not 
specifically teach the use of IP address compatibility requirements as a component of software 
roles compatibility requirements. Official Notice is taken that it would have been obvious to one 
of ordinary skill in the art to include this limitation, as it is well known in the art. The motivation 
for doing so lies in the fact that a compatible IP address must exist for the invention to function. 
Therefore, it is necessary to include this criterion in the software's compatibility requirements, as 
the IP address compatibility is an integral part of the software's compatibility. The inclusion of 
the limitation gives rise to the proper function of the invention and is thus obvious. 

As per claim 65, Spencer-Fascenda teaches the method of claim 1, and identifies 
configuration parameters to facilitate a rollback procedure (Spencer: column 9, lines 16-62), but 
does not specifically teach the specific identification of a VLAN associated with the network 
device. In view of the necessity of monitoring the configuration of the network components in 
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preparation for a rollback, Official Notice is taken that it is obvious to one of ordinary skill in the 
art at the time of the invention to specifically include the identification of a VLAN. Doing so 
would add a characteristic to monitor during a rollback, and therefore the rollback can be 
performed in a more specific manner, pertaining solely to the VLAN in question. This teaching 
would allow for more efficiency into the invention of Spencer-Fascenda and therefore would 
have been obvious to one of ordinary skill in the art at the time of the invention. 



Response to Arguments 



Applicant's arguments filed on January 12, 2009 have fully been considered. 

a. Spencer teaches the reception of an unsolicited command, given the automatic nature 
of the service provisioning. Spencer teaches that a user signs in and requests certain services, but 
after this initial indication, all the provisioning commands take place automatically through the 
SCOs without user intervention (column 2, lines 60-63; column 4, lines 3-31). This constitutes 
the reception of an unsolicited command. 

b. The remaining arguments are respectfully traversed by the addition of the Fascenda 
reference. 



Conclusion 
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organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
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